home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / packet / aprs75c / bbsnotes.txt < prev    next >
Text File  |  1995-07-24  |  7KB  |  120 lines
  1. BBSNOTES.txt 7.2        SUGGESTIONS FOR USING PBBS's
  2.                                    and for
  3.                INCLUDING APRS PROTOCOLS IN BBS and NODE SOFTWARE
  4.  
  5.  
  6.     One thing we have learned in maintaining an operational APRS net on 
  7. 145.79, is that it is very useful for all stations to include in the 
  8. comment field of their position report the address of their home BBS!  
  9. Then any station on the APRS frequency immediately learns how to send that 
  10. station a lengthy packet message.  If your TNC supports an internal BBS, 
  11. it is also useful to leave it on and include its unique address or SSID 
  12. in your comment field so that others can send you messages on your PBBS 
  13. even while you are running APRS!  A few stations sending keyboard messages 
  14. into a PBBS on the APRS frequency is not objectionable since the number of 
  15. packets are small and at typing speed.  Also, the PBBS owner then DOES NOT 
  16. read his mail over the air!  I encourage all stations to operate their own 
  17. PBBS maildrops on the APRS frequency; but please do not use the PBBS's to 
  18. post messages for OTHERS who must READ the message over the air.  All 
  19. stations should avoid any other general computer to computer exchanges 
  20. which would block the frequency for large blocks of time.
  21.  
  22.     The remainder of this file is intended for BBS SYSOPS and the writers 
  23. of BBS and NODE software.  Please consider the following advantages to 
  24. including APRS protocols in your station operation.  Since APRS allows 
  25. stations to see the network topology in real-time, it is ideal for 
  26. determining the locations of all neighboring BBS's and NODES and as a 
  27. general purpose FREQUENCY COORDINATION TOOL!  See the file README\
  28. FREQCORD.txt.  If BBS's and NODES simply included either the LAT/LONG or 
  29. GridSquare in a periodic UI frame, all users could see where the system 
  30. is located.  For permanent  sites such as BBS's and NODES, this beacon 
  31. could probably be transmitted once every hour or so.  This !LAT/LONG 
  32. format can be placed anywhere in the BText.  The exact format of the UI 
  33. frame should be as follows:
  34.  
  35.     BBSXX>APRS:!DDMM.xxN/DDDMM.xxW[PHGxyz/comments as desired to end of line
  36.                                   [this left bracket is the APRS BBS symbol
  37.                                    * see PROTOCOL.txt for exact formats
  38.     BBSXX>APRS:[GRidsq]Comments to end of line
  39.   
  40.  
  41.     For BBS code writers, this process can be enhanced by making the BBS
  42. respond to APRS Query packets.   On receipt of an APRS Query packet, all
  43. stations on frequency set a one minute random  timer and respond sometime
  44. in the next minute with their location.  This way, any APRS station can
  45. obtain the location of all stations on the frequency soon after comming on
  46. frequency.  The format of the APRS Query packet is W4XYZ>APRS:?APRS?.  By
  47. including the code in NODE and BBS software to respond to APRS Querys 
  48. within 10 seconds or so, the periodicity of the APRS position beacon can 
  49. easily be set quite infrequently since stations can request the BBS 
  50. position at any time.  For those concerned with physical security, the 
  51. grid square position report can be used which is ambiguous to 3 miles or 
  52. so instead of the LAT/LONG posit accurrate to 60 feet.
  53.  
  54. MAIL-FOR BEACONS:  Since APRS contains a BEACON parser to capture all BEACONS
  55. heard on frequency, this is an excellent way for stations to capture MAIL-FOR
  56. beacons from BBS's.  APRS stations simply call up their LATEST BEACONS display
  57. and see if there is any mail for them.  For this to work, APRS must see the
  58. MAIL-FOR information on the same line as the packet header.  By allowing APRS
  59. stations to see mail lists without even logging on, you are helping reduce
  60. congestion on the channel.   Be sure the BEACON is transmitted to one of the
  61. standard addresses that APRS parses: BEACON, APRS, ID, CQ, QST, etc..
  62.  
  63.  
  64. BBS POSITION DATABASES:  Finally, ambitious code writers could add code in
  65. their BBS's to capture all APRS position reports heard on frequency.  These
  66. reports could be retained in a file and be made available to local users.  One
  67. of these files, if downloaded, can be loaded by APRS users to display the
  68. locations of all stations ever heard on the frequency!  Talk about good
  69. preparations for emergency comms!  This service can even be made in real-
  70. time for Land Line BBS's.  This allows someone to remotely phone in and
  71. get the full APRS tactical picture.  A simple capture buffer for the last
  72. 80 to 150 packets heard would do it.  The best algorithm would save only 
  73. the last 160 UNIQUE packets heard on the APRS frequency.  This buffer only
  74. needs to be retained in RAM, since it is real time...
  75.  
  76.  
  77. BBS FORWARDED POSITION REPORTS:  Since we already have a worldwide packet
  78. network of BBS's which have the ability to forward a packet message anywhere
  79. in the country, I would like to see a standard message format built which would
  80. permit a mobile, roving packet station to report his location back to his home
  81. BBS on a once-a-day type basis.  Imagine that this mobile station simply posts
  82. a message on any nearby BBS which contains his position and the routing for his
  83. home BBS.  That packet message would be forwarded via the normal BBS network
  84. and arrive at the intended destination whereupon the destination BBS would in
  85. turn send out a decaying APRS POSITION beacon reporting that unit's position
  86. even if he was thousands of miles away and on the road!  As with any APRS
  87. position report, the beacon periodicity would decay from 10 minutes to once
  88. every few hours as the position report got older.  The format for such
  89. a position report for WB4APR might be as follows:
  90.  
  91. Send:    SP APRS @ WB3V.MD.USA                    Send command with Routing
  92. Subj:    APRS Posit
  93. Msg:     !3858.11N/07629.11W/040/010/Be home at 1200 Saturday.               
  94.          /EX
  95.  
  96. On receipt of such a message, the receiving BBS (WB3V) would form an APRS
  97. station reporting UI frame and transmit it periodically as follows:
  98.  
  99. WB3V>APRS:WB4APR   @051937/3858.11N/07629.11W/040/010/Be home at 1200 Saturday
  100.  
  101. As with all APRS packets, this packet would be transmitted once, then one
  102. minute later, then 2 minutes later, then 4 minutes later and so on.  This
  103. doubling ot the packet period after each transmission decays very repaidly to
  104. only 4 packets in the first 10 minutes, 3 more in the next hour and only 3
  105. more in an entire 24 hours!  This is not such a load!  This would only be 8
  106. packets in the first day and only 1 in the second!  When the period is greater
  107. than 24 hours, the message is deleted from the system.
  108.  
  109.  
  110. BBS POSITION DATABASE:  Since APRS includes an individual station query
  111. capability, a BBS that has accumulated the position of all of its users, 
  112. could respond to such an APRS query with a one time position report for 
  113. that station without even logging on.  The APRS query is simply a one line 
  114. APRS message from the querying station to the Queried station with the 
  115. letters "?APRS" in the first 5 character positions.  A BBS with a callsign 
  116. data base seeing such a packet could respond immediately with a position 
  117. report for that station!  The APRS station would see the position on 
  118. his map!
  119.  
  120.